For the purposes of the following description, authentication can be understood to be the act of proving to a computer-based system (known as an authenticator) that a user is who she or he claims to be. User authentication is often described in terms of three factors:                Something you know (e.g. password)        Something you have (e.g. ATM card)        Something you are (e.g. fingerprint).Authentication is the process of verifying one or more of these factors.        
For example, a typical computer user is required to authenticate himself for a wide variety of purposes, such as logging in to a computer account, retrieving e-mail from servers, accessing certain files, databases, networks, web sites, etc. In banking applications, a bank account holder is required to enter a personal identification number (PIN) in order to access an automated teller machine (ATM) to conduct a banking transaction.
The main problem to be solved is authenticating in a convenient and secure way. For example, people often do financial transactions throughout the day on the Internet, and the more convenient it is, the more likely they will buy things. The more secure it is, the more merchants and customers will use it. As another example, people often do security access throughout the day (e.g. passing through doors or accessing their computer). The easier it is to do these things, the more people can focus on the work at hand and not be distracted and frustrated by the inconvenience of repetitive interaction with security access.
Many systems for user authentication are available although none are completely satisfactory. For example, existing authentication solutions are usually one or two-factor and have a user do one or both of the following: a) Show, insert, or swipe a security token; b) Type a password, personal information or personal identification number (PIN), also called credentials.
A token is a generic term for a physical object that has a unique identifier or other information and can be communicated in some way. For example a token can be a physical card with embossed-plastic, magnetic-strip, or programmable memory. A smart card contains programmable-memory and a microprocessor for file maintenance and encryption and generally adheres to an industry standard. RFID tags are another type of token and use a short-range magnetic field to communicate, and often to power themselves. Different versions can act as a memory or smart cards.
An example where only a token is required (single factor) is a “dongle” attached to a USB port of a PC that allows software applications to be used. These dongles are constantly being bypassed with software “cheats”, available on the Internet.
Many devices have unique IDs and use a secure link with a network based on this. For example, a Bluetooth headset communicating to a computer or cell-phone uses such a device-dependent link. In Bluetooth, the user is required to “pair” two devices (a master and a slave, each with a unique IEEE EUI-48 address) by entering a PIN code in the slave. This results in an authentication of shared secret keys between master and slave, generated from the PIN, a random number, and unique ID of the slave. If the keys are not identical the slave is not authenticated and pairing is denied. It should be understood that instead of a Bluetooth link another, similar wireless link may be substituted, such as Wibree, Wi-Fi, UWB, etc. Alternatively the link could be a wired connection.
An ATM transaction is an example of two-factor authentication. The ID card is inserted (factor 1) and a PIN (factor 2) is entered. This is considered more secure than online purchases because of the multiple factors. More recently for online transactions, ID cards can now display a temporary password that can be typed in after user name and password. This brings online transactions to two-factor security level as well.
Using tokens and/or passwords is both tedious and often not very secure. For example, others can see or overhear passwords, and steal credit cards and RFID tags. A major problem is remembering multiple passwords and users are forced either to use the same password for all authentication systems (not secure) or forever recover/reset passwords as they become forgotten. Furthermore a user is often required to fish a token out of a pocket or purse, which can be a major inconvenience in crowded or hurried situations.
As other examples, input/output (I/O) devices can be used. Typically, users authenticate themselves using passwords, ID-cards and/or biometrics to an authentication system through one or more I/O devices separate from the user. Input is for taking in passwords and biometric data or reading ID-cards. Output is for displaying secret codes or menu prompts.
Examples of an authentication system using an I/O device are a user entering a password using the keyboard (I/O device) to access the network (authenticator). Another example is placing an RFID tag near a tag reader (I/O device) to unlock a door (authenticator). One final example is making a purchase at a supermarket, by swiping a credit card in a reader displaying the purchase amount (I/O device), signing with an electronic pen (I/O device) at the cashier (authenticator).
Some system designers increase security by adding an I/O device that performs biometric sensing (something you are). Adding this third-factor of authentication to the authenticator makes stealing things harder, or alternatively can (in theory) allow other factors to be dropped. However, biometrics are still considered by many to be costly and not completely reliable. Examples of biometrics are voice authentication (requiring a microphone I/O device) and fingerprint reading (requiring a finger scanner I/O device).
As a final example, a phone-delivered stock transaction is an example of a limited use of biometrics as part of a two-factor authentication. Not only does the user provide something he knows like his mother's maiden name (factor 1) but the authenticator records his voice for possible later verification (factor 2). In fact, he must talk to a person (rather than leave a message). This person ensures that it is a live conversation and not just a playback (increasing the security value of the factor). Unfortunately, today, there are voice synthesizers that can dynamically create voices (based on text entry) that meet many of the biometrics of a person, created from an earlier recording, pulling out their voice's salient features. Therefore, the security level of this practice by stock brokerage firms will soon approach the single-factor security level of online stock transactions, which are already acceptable in online transactions.
Often, the authenticator (person or software that wants to authenticate the user) makes use of an authentication/identity server. An authentication identity provider/server does the following with respect to the authentication state of the user to the authenticator:                Takes in user specific data (password, card ID, biometrics hereafter called “credentials”)        Analyzes credentials and determines authentication status        Records when a successful or failed authentication occurs        Monitors authentication expiration time for a given user        Revokes authentication under specified conditions or events (timeout for example)        Reports to requestors the authorization status of a given user        Provides a cookie/ticket/certificate/key, which are typically small amounts of digital data (hereafter called “digital credentials”) to an authenticator (a website server for example) or user agent (browser software for example).        
The server contains an analyzer. It examines the user/password data, token information or biometric data and generates digital credentials based on this data. The authenticator has shared data or a database for its users and compares the digital credentials received from the server to its data.
Often, the authentication server and the authenticator are co-located. In particular, the server can be a subsystem of the authenticator. A personal computer for example has a logon software subsystem dedicated to authenticating the user (authentication server), and software subsystems (authenticators) which check the status before proceeding. The user, server, and authenticator follow a protocol to authenticate the user. There are many authentication protocols in existence and/or being developed. Examples are OpenID, SAML, and Kerebos.
When queried by an authenticator, the authentication server indicates (serves) this state to the authenticator by sending the digital credentials. In some cases (Kerebos for example), a software “user agent” retains the digital credentials (called tickets) and gives them directly to the authenticator as needed. If the digital credentials are stored, this eliminates the need for the user to re-enter their credentials directly the next time they are needed by the same authenticator.
One problem is knowing when the user authentication is no longer valid. This is typically achieved with a time-out. For instance an ATM window will close down, or the computer screen will lock. However this is sometimes annoying because the user may still be valid and is forced to re-enter credentials.
Data integrity can be provided to the digital credentials. This ensures that they are from the specified source rather than manufactured or copied by a malicious attacker. It furthermore can ensure that nothing has been modified. Examples of data integrity are Digital Signatures and message authentication codes (MACs).
Digital Signatures are encrypted certificates that use public/private key ciphers and are usually traceable to a trusted root source. This is currently available on PC email systems for sending signed and encrypted email. First a certificate is made containing at a minimum, the public key and the signed certificate of the source of the keys (the certificate authority or CA). It may also contain other information (like user name, validity date, and a hash of the data being sent).
Then the private key (known only to the source) encrypts (signs) a hash of the certificate. Hashing is the process of taking a large piece of data and mapping it into an almost unique fixed length of data. This is done because private key encryption is generally more computationally intensive than shared key encryption. If desired, the data and certificates can be encrypted (typically with a symmetric key), but this is not required.
The encrypted certificate hash can only be decoded using the public key associated with the private key, ensuring the source. The receiver can perform the same hashing algorithm and if they get the same hash as the decrypted value, the data has not been corrupted. Furthermore, they can apply this to the embedded signed CA credential and verify the CA certificate has not been corrupted and the public key truly came from this source. This can continue to a root trusted source (like Verisign).
MACs rely on shared symmetric keys known by both parties. The digital credentials are encrypted (signed) using these shared keys. (A hash can be encrypted instead, as in a digital signature). Since the parties share the same key, they can decrypt each other's information and conclude that the other party is the trusted source. Bluetooth pairing relies on this mechanism. The shared key is the PIN, and this is used to encrypt digital credentials to confirm the device is acceptable to be paired with. In both cases (MAC and Digital signatures), if the data has been changed, it will show up in the decryption/comparison process.
Another issue is that of the authentication credential cache and key-rings. As mentioned, the authenticator and authentication server are often located in the same place. However, a remote authenticator may wish to establish indirectly that a user is authenticated. This is done by the remote authenticator asking a trusted authentication server about a user's status. Some authentication systems are calling this concept of a collection of trusted authentication servers a “federated identity”. This would allow remote authenticators to query and use the digital credentials supplied by a local authentication server. In some systems (Kerebos for example), the digital credentials can be authentication server-generic (called a ticket granting ticket) and the remote authenticators interact directly with the user agent rather than a server.
In order for this to work without requesting credentials from the user again, the server (or user agent) must store the user's digital credentials (or possibly just credentials). The location where one or more digital credentials are stored at an authentication server will be called here an authentication credential cache. In this case, a server with a credential cache can send digital credentials previously stored, to a remote authenticator. If a user agent (like a browser) stores the digital credentials from one or more authentication servers, it will be called a key-ring.
An example of this is when the user logs onto his computer, he has authenticated himself to his computer (regardless of whether the network is attached or not). When attached to his PC, the network server (a remote authenticator) consults the software on his PC (the local authentication server) to determine whether he is authenticated. He typically does not have to log on manually to every server his computer networks with. In this case, the PC is acting like an authentication server with a credential cache providing the user authentication to the network.
Furthermore, a user can have his PC remember websites that request usernames and passwords and have the computer automatically enter this data. This is very much like a key ring in that the user doesn't have to remember and enter the password for each site himself. The data is stored encrypted. However, once he has logged into his computer, if this feature is enabled, anyone can enter his username and password.
Recently, applications are being developed where cell phones and PDAs can act as the I/O device (taking in passwords or biometrics, or displaying secret data or code) for an authentication system. Furthermore, the cell phone or PDA can have a unique ID number. The effect of this is that the cell phone becomes effectively a token(something you have).
If the cell phone/PDA has an I/O interface, the authentication system no longer needs to provide an I/O device which can be costly, malfunction, or be vandalized. Furthermore, by adding the unique ID to the combination device, a separate token does not need to be carried. Some cell phones are adding fingerprint readers as well for biometrics. The user still has to enter a password repeatedly for transactions (to make theft of the possessed object less risky).
The alternative to this is having the cell phone/PDA act as an authentication server with credential cache. However, this makes the stealing of that object much more of a risk once the user has authenticated to it.
It can now be understood that improvements to user authentication systems are needed.